Defining a ‘Customer’ Entity (Teams Tenant)
Network operators can add a logical ‘customer’ entity (Teams tenant) to the ARM GUI in the Customers page. The page allows add +, edit, delete, Lock/Unlock and Refresh actions for each ‘customer’ entity.
Before implementing the feature, best practice is for operators to decide how to identify a ‘customer’ entity: using either Prefix Groups, or ARM Users. Note that a combination of the two is also supported, but may be less convenient.
For more information and a use-case for each ‘customer’ definition method (either with Prefix Group or with Users), see Defining ‘Customer’ Entities using ARM Users & Policy Studio.
➢ | To add a new 'customer' entity': |
1. | Open the Customers page (Network > Customers). |
2. | Click add +. |
3. | Configure the parameters using the following table as reference. |
Add Customer
Parameter | Description |
---|---|
Name |
Mandatory. Unique name of the ‘customer’ entity. Configure an intuitive name to facilitate effective management later. |
Prefix Group |
Used if the operator chooses to identify a ‘customer’ entity with Prefix Groups. The operator can select a Prefix Group or several Prefix Groups previously defined (Settings > Call Flow > Prefix Group). Multiple Prefix Groups are treated as ’or’ in terms of ‘customer’ entity definition (DIDs and ranges from all the selected Prefix Groups are considered to belong to the ‘customer’ entity). A Prefix Group can include not only full DIDs but also ranges. Note that the same Prefix Group cannot be used for several ‘customer’ entities as it uniquely identifies ‘customer’ entity DIDs. However, the ARM does not prevent a collision between the ranges of Prefix Groups; it’s the operator’s responsibility to prevent a collision of ranges between ‘customer’ entities. |
Policy Studio Tag |
Used if the operator chooses to manage ‘customer’ DIDs in the ARM Users page and thereby benefit from ARM Users capabilities (such as Policy Studio with pre-routing manipulations or Users Groups). The Policy Studio Tag should be provided in the Policy Studio (for incoming and outgoing calls) and is used by the ARM mainly for CAC counting and enforcement for specific ‘customer’ entities / Teams tenants. The extension for this Tag in a Policy Studio action is described under Customers Page. |
SIP header |
Each unique ‘customer’/Teams tenant making outbound calls is identified/marked by Teams with the FQDN in the ‘Contact’ or ‘From’ header. A call in the direction ‘to Teams’ should have this ‘Contact’ header identification as well. From Teams’ perspective, this is the way to identify and distinguish between ‘customer’ entities / tenants. The ARM provides an easy way to put the predefined string (the one used by Teams to identify a tenant) in the ‘Contact’ header for calls toward Teams (for more information about this option, see under Customers Page. The SIP header attribute allows the operator to provide a string to be used for the ‘Contact’ header. Note that it should be coordinated with the Teams settings for the ARM ‘customer’ entity / Teams tenant. |
CAC profile |
Can optionally be attached per ‘customer’ entity. For a description of a CAC profile and its capabilities, see CAC Profiles). The operator can attach a CAC profile to a ‘customer’ entity with both directions or a one-direction sessions limitation (defined under Settings > Routing > CAC profiles). Operators can reuse the same CAC Profile for multiple ‘customer’ entities.
|